home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / STUTTGART / LANG / C / LIB / DESKLIB / CORE / DeskLib / Docs / Future < prev    next >
Text File  |  1995-09-03  |  2KB  |  71 lines
  1. Here are a few things I want to do in the next release of DeskLib, in
  2. addition to adding code sent in by DeskLib users. 
  3.  
  4. Some of these ideas have been suggested by such DeskLib users. 
  5.  
  6. I would be very keen to hear from people who have any comments or
  7. suggestions.
  8.  
  9.  
  10.  
  11. Const
  12. -----
  13.  
  14. DeskLib functions should make more use of 'const' in function arguments,
  15. as this makes things a little more robust.
  16.  
  17.  
  18. Debug version
  19. -------------
  20.  
  21. I'd like to have a 'Debug' version of DeskLib, which would be compiled
  22. with 'DeskLib_DEBUG' predefined. The .o files for this would be in a
  23. 'Debug' directory within each sublibrary directory. This would use
  24. variables like 'event_debuglevel' to control how much diagnostic
  25. information is output (using Debug_Printf). Calls to 'DebugX_Printf()'
  26. would have to be added to the libraries to make this worthwhile.
  27.  
  28.  
  29. Error handling
  30. --------------
  31.  
  32. I'm thinking of having a global function-pointer 'desklib_errorfn'
  33. which, if not NULL, is called by all library functions if an error
  34. occurs. The user could then provide an error-handling function which
  35. uses longjmp to restore control, returns to just after the place where
  36. the error occured (after sorting everything out of course), or quits
  37. gracefully).
  38.  
  39. This would eliminate the need for user code to check the returned
  40. 'os_error *' from many library functions. Some functions would still
  41. return an 'os_error *' even if an error handler function is registered,
  42. for example if a SWI uses the 'os_error *' mechanism in circumstances
  43. which don't qualify as serious errors.
  44.  
  45. There could also be a global structure which contains information about
  46. the error. This would enable the user to know what has gone wrong if
  47. setjmp returns non-zero.
  48.  
  49.  
  50. Memory allocation functions
  51. ---------------------------
  52.  
  53. A set of function prototypes 'DeskMem_Malloc,Calloc/Realloc/Free' could
  54. be used, with simple implementations which simply call
  55. malloc/calloc/realloc/free and deal with an out-of-memory situation by
  56. calling 'desklib_errorfn'. The user could provide alternatives, eg ones
  57. which call Mem_ functions.
  58.  
  59.  
  60.  
  61. RISC OS version handling
  62. ------------------------
  63.  
  64. Have a macro RISC_OS_VERSION which can be set by the user, which enables
  65. different versions of functions, such as Window_GetInfo. This will allow
  66. programs to be compiled to run on specific versions of RISC OS.
  67.  
  68.  
  69.  
  70. - Julian Smith
  71.